1. Field of the Invention
This invention relates to mapping XML Schema definitions to objects. More specifically, the invention relates to mapping XML Schema definitions to objects such that a simple interface for the object is presented to the client which is easy to understand, while the complicated internal aspects of the object related to advanced features of XML Schema are still maintained in the object, but hidden from the client.
2. Description of the Related Art
XML has become a ubiquitous member of the computing landscape, providing a human-readable and portable format for data exchange. However, many applications are designed to work with, or simply work better with, object representations of data as opposed to an XML representation. As a result, a number of solutions exist which map XML Schema definitions (which describe and define the structure of an XML document) to objects; for example, the Eclipse Modeling Framework (EMF), Service Data Objects (SDO), or JAXB all provide solutions. The solutions mentioned generate various types of XML representation object models which allow an XML document to be treated as an object. The above solutions are not restricted to representing only XML documents as objects and may be used to translate various formats to objects; for example, SDO may also be used to translate models such as those developed using IBM's Rational Rose software to objects.
XML, however, poses a unique modeling challenge. In many instances, the richness and flexibility of XML Schema complicates the translation process. XML Schema features such as wildcards, substitution groups, and repeated model groups do not intuitively map to obvious object properties. As a result, the object model may contain properties which a typical user may not understand, making the use of these objects a more complicated process. In this field of endeavor, the term ‘user’ or ‘client’ referenced above refers to software developers. Thus, technologies for implementing mapping of XML Schema definitions have had to choose between simplicity (where the advanced features are simply ignored) or completeness (where the advanced features are mapped and presented to the user).
For example, a part of an XML Schema may specify the following:
<xs:element name=“RealEstate”>  <xs:complexType>    <xs:sequence>     <xs:element name=“building” type=“xs:string”/>     <xs:element name=“owner” type=“xs:string”/>     <xs:element ref=“tenant”/>   </xs:sequence>  </xs:complexType></xs:element><xs:element name=“tenant” type=“tenant”/>  <xs:complexType name=“tenant”>    <xs:sequence>     <xs:element name=“name” type=“xs:string”/>    </xs:sequence> </xs:complexType>...</schema>The above maps to the simple Java interface below:
public interface RealEstate { String getBuilding( ); void setBuilding(String value); String getOwner( ); void setOwner(String value); String getTenant( ); void setTenant(Tenant value);}
The model above is simple and easy to understand by one of skill in the art. However, as shown below, additional complexities may appear when the schema contains additional XML features:
<xs:element name=“Realestate”> <xs:complexType>  <xs:sequence>    <xs:element name=“building” type=“xs:string”/>    <xs:choice maxOccurs=“unbounded”>      <xs:element name=“individualOwner” type=“xs:string”/>      <xs:element name=“corporateOwner” type=“xs:string”/>    </xs:choice>      <xs:element ref=“tenant”/>  </xs:sequence> </xs:complexType></xs:element><xs:element name=“tenant” type=“tenant”/> <xs:complexType name=“tenant”>  <xs:sequence>    <xs:element name=“name” type=“xs:string”/>  </xs:sequence> </xs:complexType><xs:element name=“ratedTenant” substitutionGroup=“tenant” type=“ratedTenant”/> <xs:complexType name=“ratedTenant”>  <xs:complexContent>    <xs:extension base=“tenant”>      <xs:sequence>        <xs:element name=“rating” type=“xs:int”/>      </xs:sequence>    </xs:extension>  </xs:complexContent> </xs:complexType>. . .</schema>The above maps to a more complicated Java interface below:
public interface Realestate {  String getBuilding( );  void setBuilding (String value);  String getIndividualOwner( );  void setIndividualOwner (String value);  String getCorporateOwner( );  void setCorporateOwner (String value);  String getTenant( );  void setTenant(Tenant value);  FeatureMap getGroup( );  FeatureMap getTenantGroup( );}A typical user will not have need for, nor understand, the FeatureMap getGroup( ) and FeatureMap getTenantGroup( ) aspects of the interface. The information represented in these statements pertains to the internal features of the XML Schema document; in most instances, these internal features relate to structural features of the data, as opposed to the substance of the data itself.
The presentation of this additional information will often confuse the user since the information does not correspond to the expected, user-defined properties of the XML document such as the building, owner, etc. As mentioned above, one possible solution is to simply choose not support these additional features and remove them from the schema-to-object mapping implementation. However, this additional information is needed to accurately represent all aspects of the XML Schema. For example, if at some point the client attempts to map from the object to an XML document, the XML document may be incomplete in comparison to the original if the advanced features defining the structure of the data were removed.
Technologies which choose completeness impose additional burdens on their clients, who need to be able to distinguish simple from advanced properties and know which ones to use in order to obtain the desired results. Technologies which choose simplicity lose information that may be of use to advanced users, and also lose the ability to accurately reproduce the XML document from the object.